NIST AI 600-1: register the framework and transcribe its 211 suggested actions - #187

Thanks, @Prasad-desh. This is careful work, and the notes for reviewers made it quick to check.

Verification of this branch (2559544), local runs:

• Against current main: validate 0 errors (93 warnings, same as main), stats:check current, 92/92 unit tests, and a second generate.js + stats + render-stats produces no drift.
• Ids: checked against the published PDF (NIST.AI.600-1.pdf from nvlpubs). It has 212 distinct id-shaped strings, and the only one missing from the registry is GV-1.1-002, which appears only in the Action ID explanation. That confirms your reading. 211 ids, no duplicates.
• Descriptions: all 211 match the PDF word for word, checked as an in-order word match near each id so the GAI-risk column can't interfere. The only differences are the ones below.

One fix needed: 13 descriptions keep a line-break artifact. Where a hyphenated compound wrapped at the hyphen, the line break became a space, so the text reads non- systematic instead of non-systematic:

GV-6.2-002 open- data · MS-1.1-006 red- teaming · MS-2.2-004 privacy- enhancing · MS-2.5-001 non- systematic · MS-2.5-002 retrieval- augmented · MS-2.5-003 pre- deployment · MS-2.8-003 tamper- proof · MS-2.11-002 sub- sampling · MS-3.3-003 AI- generated · MG-2.2-002 AI- generated · MG-2.2-008 AI- generated · MG-3.1-001 third- party · MG-3.2-002 pre- trained

Six of the derived titles carry it too (GV-6.2-002, MS-2.5-001, MS-2.5-003, MS-3.3-003, MG-2.2-002, MG-2.2-008). Each one is a genuine compound in the PDF, so the fix is to drop the space and keep the hyphen. A /\w- \w/ search over the file finds exactly these.

One claim to correct: 14 parent values don't resolve against nist-ai-rmf.json. The description says every parent resolves there, but four subcategories aren't in that registry: MP-3.4 (6 actions), MS-2.12 (4), MG-4.3 (3) and MS-2.13 (1). nist-ai-rmf.json only holds the subcategories that existing mappings cite. Nothing validates this today, so the branch is green either way. Two ways to fix it: add the four subcategories to nist-ai-rmf.json as curated parents, transcribed from AI RMF 1.0, or reword the claim and the $comment. Adding them changes the AI RMF control count, so the maintainer should choose.

The exports.test.mjs change looks right to me. A registry nothing cites can't emit OSCAL, and the skip exempts nothing that does.

Left for the maintainer (my view in brackets, not a ruling): the title-derivation rule (verbatim text stays in description, so nothing is lost), keeping the 49 subcategories out of this registry (agreed: it protects the denominator), dropping the stub mapping files (the REQUIRED_SECTIONS conflict you describe is real), and the branch name (harmless).

Merge-order note. This PR and #184 both change data/stats.json (the control total), so whichever merges second will show a conflict in that file. I simulated main + #184 + #185 + #186 + this PR: that file is the only conflict, and regenerating fixes it. After generate.js + stats + render-stats: 0 errors, 93/93, no drift.

CI hasn't run here. Workflows on fork PRs wait for a maintainer to approve them, so every result above is from a local run, not a GitHub check.

Following up with the maintainer's decisions, so you know exactly what's needed to merge.

The four calls you asked about are settled your way. The title-derivation rule stands, the 49 subcategories stay out of this registry, the stub mapping files stay out, and the branch name is fine.

Needed before merge:

1. The 13 hyphenation fixes from my earlier comment (non- systematic → non-systematic, and so on, including the six titles derived from them).
2. The 14 unresolved parent values (MP-3.4, MS-2.12, MG-4.3, MS-2.13). Simplest fix: reword the claim in the $comment and the PR description to say the parents are AI RMF subcategory ids, of which these four aren't in nist-ai-rmf.json yet. Adding them to nist-ai-rmf.json is also fine, provided they're transcribed verbatim from AI RMF 1.0.
3. One addition: transcribe the GAI risk tags for each action. Every suggested action in the PDF carries a "GAI Risks" column, tagged with one or more of the document's 12 risks (Information Security, Confabulation, Data Privacy, …). That's NIST's own data, so copying it is transcription, not security judgment, and it's the most useful part of the document for this crosswalk. It turns the later human mapping job from 51 entries × 211 actions into 51 entries × 12 risks, followed by confirming candidate actions. Suggested shape, per control: "gai_risks": ["Information Security", "Confabulation"], using the risk names exactly as the document spells them. Add a test that every value is one of the 12. data/framework-schema.json doesn't forbid extra properties, so no schema change is needed.

Also landing separately: #188. The webapp home page counted every registry as a framework, so this PR would have shown 27 frameworks on the live site while the README says 26 mapped, and added 211 unmapped controls to the headline. #188 makes the home page count mapped frameworks only. It doesn't touch your files, and with it merged, this registry can land without changing any public number until the first rows map to it.

After merge, a framework-owner reviewer will author the mapping rows (per #119 and STRAT-04). Thanks again. The transcription itself checked out to the word.

got it @emmanuelgjr , will do the changes. thanks for the updates

@emmanuelgjr all three done, rebased onto main at 633c59a with the data/stats.json conflict resolved.

1. Hyphenation. Fixed, including the six derived titles, which are regenerated from the corrected text rather than patched. The cause was mine: the extraction joined words across a line break without rejoining compounds at the hyphen. The parser now does, and a /\w- \w/ search over the file returns nothing.

2. Parent claim. Reworded rather than adding the subcategories, so the AI RMF control count is untouched. The $comment and the PR description now name MG-4.3, MP-3.4, MS-2.12 and MS-2.13 as the four not in nist-ai-rmf.json, and say why.

3. gai_risks. Added for all 211 actions from the GAI Risks column, with a test asserting every value is one of the twelve and that all twelve are exercised, so a typo in the list can't pass unnoticed.

Two things the risk column turned up that need your call:

• The tables spell four risks differently from the section 2 enumeration: Harmful Bias and Homogenization (57 rows), Environmental (4), CBRN Information and Capability (2) and Human AI Configuration (1). I normalised to the section 2 names, since those define the twelve and the test checks against them; the variants are recorded in the $comment. Happy to keep the table spellings and widen the test instead, if you would rather the field be literal.
• GV-1.4-002 carries a fifth tag, Civil Rights violations, which is not one of the twelve and appears nowhere else in the document. I left it out of gai_risks and noted it in the $comment, rather than dropping it quietly or admitting a thirteenth value.

Verification on the rebased branch: npm test 93/93, where a clean clone of 633c59a is 89/89. validate.js 0 errors and 91 warnings, identical to that clean clone. npm run build deterministic across two runs, git status showing only the intended files. Control total is 1184, which is 973 after #184 plus these 211.

Understood on #188 landing first. Thanks for checking all 211 against the PDF; the two things you caught were both mine.

Thanks, @Prasad-desh. All three changes check out, and I verified the new risk tags independently.

Verification of 6c2354f, local runs against main at cc0a735 (after #188 and #190):

• validate 0 errors (92 warnings, same as main), stats:check current, 94/94 unit tests, and a second generate + stats + render-stats produces no drift.
• Webapp: with this branch, the home page still shows 26 frameworks and the same Registry Controls total. The Webapp: count only mapped frameworks in the home-page headline #188 test passes on this head, so the registry lands without changing any public number.
• Hyphenation: the /\w- \w/ search returns nothing, and all 211 descriptions still match the PDF word for word.
• gai_risks: I read the GAI Risks cell of every action straight from the PDF's tables (pdfplumber, cell by cell, rather than from flattened text). The tags match on 211 of 211 actions, with no tag missing and none extra.
• Parent wording: the $comment and the description now name the four subcategories that don't resolve, and why.

Your two calls: I'd keep both as you have them.

1. Normalising to the section 2 names is right. The twelve are defined in section 2, which makes gai_risks a closed vocabulary that consumers can filter on, and your test enforces it. I confirmed the table variants exist (e.g. "Harmful Bias and Homogenization", "CBRN Information and Capability", "Human AI Configuration"), and recording them in the $comment keeps the transcription honest.
2. "Civil Rights violations" on GV-1.4-002: confirmed in the PDF, where the cell reads "…Data Privacy; Civil Rights violations". Keeping it out of gai_risks and noting it in the $comment is the right handling. Admitting a thirteenth value would break the vocabulary, and dropping it silently would lose data.

From the review side this is ready. Next, the maintainer approves the fork CI run, and the PR merges once the checks are green.